AWS再入門ブログリレー Amazon DocumentDB編

はじめに 本ブログリレーについて

当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2019』の4日目のエントリです。昨日はKitano Yuichiによる「Amazon SES」でございました。

このブログリレーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWSをこれから学ぼう！という方にとっては文字通りの入門記事として、またすでにAWSを活用されている方にとってもAWSサービスの再発見や2019年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

では、さっそくいってみましょう。本日のテーマは『Amazon DocumentDB』です。

目次

• Amazon DocumentDBとは
• メリット
• ユースケース
• やってみよう
• まとめ
• 参考情報

Amazon DocumentDBとは

高速でスケーラブルかつ高可用性な完全マネージド型のMongoDB互換ドキュメントデータベースサービスです。 と、これだけ聞いても¯\_(ツ)_/¯って感じですよね。各要素について、もう少し詳細に説明します。

ドキュメント(指向)データベース

RDBでいうところの各レコード(ドキュメントデータベースではドキュメントと言います)にJSONライクなデータを格納するデータベースのことを指します。 RDBでいうテーブル(ドキュメントデータベースではコレクションと言います)の各レコード（ドキュメント）のJSONの構造は同じである必要はありません。またレコード（ドキュメント）を更新する際も、元と同じ構造を維持する必要もなく、新しい要素(フィールドと言います)を追加したり、逆に削除したりしても構いません。RDBのように厳密にスキーマを管理する必要がないので、より柔軟に利用することができます。

(補足:ややこしいのでRDBとの用語対応表を貼っておきます)

RDB	ドキュメントデータベース(MongoDB)
データベース	データベース
テーブル	コレクション
行(レコード)	ドキュメント
列(カラム)	フィールド
PK(プライマリキー)	ObjectId

※ DocumentDB開発者ガイドより引用（一部追加、抜粋）

例:ふたつのドキュメントが格納されていますが、その構造は同じではありません

{
"_id" : ObjectId("5d18760d11a12c05cac220e1"),
"name" : "kazue",
"age" : 32,
"like" : [
"music",
"soccer"
]
}
{
"_id" : ObjectId("5d18765911a12c05cac220e2"),
"name" : "yamada",
"age" : 25,
"job" : "sales",
"birthplace" : "Osaka"
}

例:各ドキュメントは要素(フィールド)を自由に追加、削除できます

{
"_id" : ObjectId("5d18760d11a12c05cac220e1"),
"name" : "kazue",
"age" : 32,
"like" : [
"music",
"soccer"
]
}

↓ "age" 削除、 "blood-type" 追加↓

{
"_id" : ObjectId("5d18760d11a12c05cac220e1"),
"name" : "kazue",
"like" : [
"music",
"soccer"
],
"blood-type" : "b"
}

MongoDB互換

MongoDBはドキュメント指向データベースの中で最もメジャーな製品です。 DocumentDBはMongoDB(MongoDB Community Edition3.6)との互換性があるので、各言語に存在するMongoDBを扱うためのSDKやライブラリがそのまま使用できます。 また、AWS DMS(AWS Database Migration Service)を使ってEC2上で稼働しているMongoDBを容易にDocumentDBに移行することもできます。

高速&スケーラブル

データ読み込みに関しては、リードレプリカを最大15台まで増やしていくことができ、最大秒間100万リクエストが実行可能になります。 一方データ書き込みに関しては、プライマリインスタンスのメモリ容量を数分以内にスケールアップすることができます。最大メモリ容量は768GBです。 また、今回は説明を割愛しますが、ストレージレイヤがAuroraと同様のアーキテクチャになっており、非常に高速に動作します。かつ、ストレージは自動拡張します。そのためストレージのサイジングを行う必要がありません。ストレージは最大64TBまで拡張可能です。

高可用性

• 99.99% の可用性を備えるように設計されています。
• インスタンスに障害が発生した場合、自動的にインスタンスと関連プロセスを再起動します。インスタンスの再起動時間は通常 30 秒以下です。
• さらに、インスタンス再起動後もキャッシュをそのまま保持します。
• マスターインスタンスに障害が発生した場合、リードレプリカを作成している場合はいずれかのリードレプリカに自動的にフェイルオーバーします。
• ストレージボリュームは3AZに、かつ各AZで2箇所ずつ、つまり2×3=6箇所にレプリケートされます。データベースの書き込み性能に影響を与えることなく最大 2 つ、読み込み性能に影響を与えることなく最大 3 つのデータコピーの損失を透過的に処理します。
• スナップショットは自動でS3に保存されます。S3の耐久性は99.999999999%です。

DocumentDBのメリット

JSONのまま、かつスキーマレスにデータ格納できる、というのが最大のメリットかと思います。

ひとつ目、JSONのままデータ格納できるという点について。フロントエンド⇆バックエンドの連携時に、データをJSON型にしてやりとりするというのは昨今よくある構成です。ここでバックエンドから操作するデータベースとして、RDBを採用することを想定してみましょう。 フロント⇆バックエンド間のやりとりはJSONを介して行われます。一方、バックエンド⇆DBのやりとりはSQLを介してですね。間にOR Mapperも利用するかもしれません。いずれにせよデータ格納処理では、JSONデータをアプリケーション内でリレーショナルなテーブルの形に変換してからデータ格納する必要があります。特に、ネストした構造のJSONを変換するのは面倒な作業になるでしょう。 逆のデータ参照も然りで、リレーショナルなテーブルのデータをJSONに変換してクライアントに渡す必要があります。 DocumentDBをはじめとするドキュメント指向データベースを使う場合、DBに格納するデータ型はJSON(ライク)なままで良いので、データ型の変換処理をアプリケーション層でゴリゴリ書く必要性は減るでしょう。これがJSONのままデータ格納できるというメリットです。

続いてふたつ目のメリット、スキーマレスについてです。 テーブル(コレクション)単位でスキーマを定義する必要はなく、行（ドキュメント）ごとに別々のスキーマを持てるので、扱うデータの形を決めきれない時にDocumentDBは便利です。 そういう意味で、要件が変化していくアジャイル的な開発現場ではより有用なデータベースと言えるでしょう。

DocumentDBのユースケース

Webアプリケーションのバックエンドとして

前述の通り、JSONでデータ連携することが多い昨今のWebアプリケーションにおいて、JSONのままデータ格納できるというのは大きなアドバンテージです。その中でもスキーマレスな以下のようなデータを扱う際に特に役立つでしょう。

• ユーザーのプロフィールデータ（ユーザーごとに保存したい情報が異なる）
• ECサイトの商品情報（異なる種類の商品の場合は記載項目を変えたい）
• CMS（どんな項目が必要かは個々のコンテンツ次第）

すでにEC2上でMongoDBを利用している

こういった場合はぜひDocumentDBを利用されることをご検討された方が良いでしょう。 DocumentDBはマネージドサービスですので、煩わしい管理業務をAWSに任せてアプリケーション最適化に集中できます。

他DBとの使い分け

DocumentDB(MongoDB)とRDS・DynamoDB間との位置付けは、以下の弊社菊池のスライドがわかりやすいと思います。

RDSとの使い分け

トランザクション処理が求められるケースではRDSを使うのが良いでしょう。DocumentDBは現在トランザクション処理をサポートしておりません。（MongoDBでは4.0でトランザクションがサポートされましたがあくまで補助的なもの。そしてDocumentDBはMongoDB3.6互換です）

また、かっちりスキーマを決められるデータを扱う場合もRDSを使う方がシンプルで良いでしょう。DocumentDBの良さを活かすことができません。またDocumentDBの場合各レコード（コレクション）ごとにスキーマ情報も持つ必要があるため、RDSよりデータ量が大きくなりがちです。

DynamoDBとの使い分け

スケーリング性能でいえばDynamoDBの方が高いです。DocumentDBの優位性は柔軟にクエリが書ける点にあります。ですのでアクセスパターンが複数ある、もしくは読み切れない場合にはDocumentDBの方が便利です。またネストしたJSONのフィールドにもインデックスを貼ることができる、というのもDocumentDBの強みです。

やってみよう

開発者ガイドに開始方法についてのページがありますので、こちらを参考に一度クラスターの作成からmongoシェルを介してのデータ操作を試してみてください。

Amazon DocumentDB 開発者ガイド 開始方法

こちらのガイドで紹介されているデータ操作は、挿入、検索、更新、削除のみですが、以下のページにそれ以外の操作方法についてもまとめられています。余力があればこれらの操作もお試しください。

Amazon DocumentDB 開発者ガイド ドキュメントでの作業

DocumentDBは決してお安いサービスではないので、お試しになられたあとはクラスターを削除することをお勧めいたします。継続的にお試しされるのであれば、以下エントリを参考に一時停止＆再開をご検討ください。

[アップデート] DocumentDB がクラスターの停止と起動をサポートするようになりました！

まとめ

DocumentDBについてご紹介しました。私は先日AWS Summit Tokyo、AWS Summit Osakaに参加した際、AWSのデータベース系サービスをまとめて紹介するセッションを聴講しました。その中でスピーカーのAWSの方が引用されていたのは「万能なデータベースは存在しない」という amazon.com CTOの Werner Vogelsさんの言葉です。それぞれのサービスの特性を理解して、適材適所で利用することが肝要です。本エントリにてDocumentDBの特性を理解いただき、データベース選定の際にDocumentDBを選択肢の一つに加えていただければ幸いです。

参考情報

• AWS Black Belt Online Seminar
• YouTube
• SlideShare
• 開発者ガイド
• Amazon DocumentDB
• [JAWS DAYS 2019] 「Amazon DocumentDB（with MongoDB Compatibility）入門」について話しました #jawsug #jawsdays #jd2019_d

再入門シリーズ 明日（7/5）は

もきゅりんの「AWS Step Functions」編です。お楽しみに！！